chore(create-app): update svelte templates #2611
Conversation
…in-svelte Adds technical considerations to README Remove unnecessary complexity from store
GrygrFlzr
force-pushed
the
create-app-svelte
branch
from
006d00f
to
f85b94b
Compare
|
@antfu we already discussed this with @GrygrFlzr in Discord, and I tested both templates locally. I think we can merge after your review. |
|
Though: it is interesting that the Svelte plugin will live out of Vite's monorepo while the Vue and React plugins live in Vite's monorepo. I don't think it is bad since it is good that the Svelte team can modify the plugin without going through Vite's PR process. Maybe at one point in the future, the Vue and React plugins may also end up being maintained in separated repositories. |
| export function getStore<T>(id: string, initialValue: T): Writable<T> { | ||
| return stores[id] || (stores[id] = writable(initialValue)) | ||
| } |
There was a problem hiding this comment.
Would it be best if we only export a counter store? This might probably break HMR, but it's weird to have this pattern in the starter template.
Or we can also simplify this and have a normal count variable in Counter.svelte with // @hmr:keep per rixo's idea in Vite Land?
There was a problem hiding this comment.
this getStore function originated from a playground in svite where i used it for testing purposes. I think it is overkill in a minimal starter template and may not even be a good idea in production use in general.
+1 for a more simple solution
There was a problem hiding this comment.
From what I can tell our options are:
- straight up an external
writable()store with no id:State is preserved across all updates except toimport { writable } from "svelte/store"; export default writable(0);
store.jsitself, which is intuitive, but also doesn't reflect how people use local state in components. // @hmr:keepon the single counter variable// @hmr:keep-allon the componentpreserveLocalStateinvite.config.js- but this was disabled by default for a reason.
With options 2-4, state is lost upon updating App.svelte, as the Counter component is recreated. We're just picking which flavor of poison to go with.
There was a problem hiding this comment.
I discussed this further with dominik over Discord and decided on a fifth option: the default of no local state preservation. The crux of the issue is that its complicated enough to hide behind flags, so like @sveltejs/kit it's likely best to keep disabled, and the behavior can be explained in the README.
There was a problem hiding this comment.
I strongly believe we should go with option 2. It sidesteps most difficulties, and hints just the right amount of information to maximize people's understanding and learnability.
Enabling preserveLocalState by default goes against the grain of "no friction HMR", I believe, because its behaviour is hard to anticipate and predict intuitively. Because of this, it makes HMR feel more fragile and unreliable than it actually is, hence lessening its value for the user (HMR value is all about being confident that your change are reflected the same way they would be without it, any glitch or unpredictability eats hard into this confidence). Furthermore, the difficulties created by preservation of state are all but exacerbated in Svelte, since any random let variable is a piece of state in Svelte components.
Stores sure are cool and all, but I don't think they have much to do with HMR at this point. State existing in other modules that are not traversed by a HMR bubble is always preserved (otherwise that wouldn't be HMR). Also, there's little doubt that a user of Svelte will soon enough be exposed to lot of documentation and information about them. As such, HMR-wise, I'm pretty neuter to have them or not to have them in a starter example.
On the contrary, most people will never read any bit of HMR docs (we don't want them to have to), and so illustrating that the capacity (preserving local state) exists, and demonstrating the existence of the // @hmr-keep comment is probably the best we can achieve. It non-obstructively hints people about the situation, giving them some hook for something to search about, if they're so inclined.
Other magic HMR comments like // @hmr:keep-all are kinda out of scope for a starter, to me... People will find about them, googling for // @hmr:keep, if they're interested into it. Otherwise, they're not so useful I guess. And HMR is not about HMR, it's about a nice dev experience, and so less docs / information / noise about it is probably the better.
There was a problem hiding this comment.
@GrygrFlzr To be clear, my last comment was started and sent before your last one, that I just discover. I still personally believe having the behaviour and magic comment trick illustrated rather than documented would probably be the best trade off, but I'm rather good with any direction this can take, except for enabling preserveLocalState by default. This one has really proven confusing and detrimental to the HMR experience in the past, and I much more prefer having the occasional user that is disappointed not to have their counter keep its value, which is really a minor inconvenience, than risking to feed and grow a general sentiment of "yet another broken HMR".
Shinigami92
added
the
p2-nice-to-have
|
I'd love to see this merged rather sooner than later. |
GrygrFlzr
force-pushed
the
create-app-svelte
branch
from
ec417e7
to
abd51a8
Compare
@svitejs/vite-plugin-svelteto@sveltejs/vite-plugin-svelteGoing forward, this will be the maintained version.
globals.d.tstosrc/global.d.tsto match SvelteKit (and iircglobal.d.tsis the more common name).import.meta.hotusage, turns out normal external stores work fine across HMR updates.